Frame synchronisation in a radio access network

ABSTRACT

A method of optimizing the timing offsets with which data frames are transmitted over the Iur/Iub interfaces of a UMTS Terrestrial Radio Access Network, UTRAN. The method comprises, for a given Iur/Iub interface or set of Iur/Iub interfaces over which identical user plane data is to be sent, defining a duration of a data frame receiving window for use by the receiving node(s), transmitting data frames from a sending node with an initial timing offset sufficient to ensure a likelihood that the frames will be received at the or each receiving node within the defined receiving window, reducing the timing offset at the sending node in a stepwise manner, and adjusting the timing offset at the sending node in response to the receipt of late Time of Arrival error reports at the sending node. In a second embodiment, the frame synchronisation of frames corresponding to speech services and data services is carried out by delaying the frames corresponding to speech services a fixed delay and the frames corresponding to data services a variable delay based on a received time of arrival feedback.

This application is the U.S. national phase of international applicationPCT/EP2003/50881, filed 24 Nov. 2003, which designated the U.S., theentire content of which is hereby incorporated by reference.

TECHNICAL FIELD

The technology relates to frame synchronisation in a radio accessnetwork and in particular to frame synchronisation between a RadioNetwork Controller and a NodeB of a UMTS Radio Access Network (UTRAN).

BACKGROUND

The Third Generation Partnership Project group, known as 3GPP, isinvolved in ongoing standardisation work on the WCDMA group of protocolsreferred to as UMTS or 3G. A UMTS operator network can be separated intoa number of major components, namely one or more core networks which areresponsible for setting up and controlling user sessions, and a UMTSRadio Access Network (UTRAN) which controls access to the air interface.The architecture of a UTRAN is illustrated schematically in FIG. 1. Theinterface between the UTRAN and the user equipment (UE) is provided bynodes referred to as “NodeBs”. The NodeBs are responsible fortransmitting and receiving data over the air interface and arecontrolled by Radio Network Controllers (RNCs). User and control data isrouted between UEs and a core network via the NodeBs and the RNCs. Theinterface between a NodeB and an RNC is referred to as the Iubinterface.

There are situations in which the same data may be transmitted between agiven UE and an RNC via two or more NodeBs. This is referred to asDiversity Handover Function (DHO). The NodeBs may be controlled by thesame or different RNCs. In the latter case, data is routed to thecontrolling (or serving) RNC via a drift RNC. The interface between theserving and the drift RNC is referred to as the Iur interface. Bothscenarios are illustrated in FIG. 1.

The user-plane protocols between an RNC, NodeB, and UE are illustratedschematically in FIG. 2. One job of these (UP) protocols is theimplementation of a Frame Synchronization function which takes care ofthe timing of frames over the Iub interface between an RNC and theassociated NodeB's. An important function influencing FrameSynchronization is the handling of the DHO scenario in which the sameframes are transmitted over a number of legs, some of which also may berelayed via a Drift RNC over the Iur interface. In the downlinkdirection, as the transmission over the air has to be synchronized, theFrame Synchronization function has to make sure that copies of the sameframe received over different Iub's/Iur's with differing delays arereceived on time for sending. FIG. 3 illustrates the framesynchronisation window at a NodeB in relation to the (DL) radio framestructure, where the time taken to process a frame at the NodeB isdefined as Tproc. In the uplink direction, the serving RNC mustcoordinate the receipt of identical frames received over the differentIub's/Iur's, and again the Frame Synchronization function must ensurethat frames are received at the serving RNC on time.

Considering further the downlink direction, a certain frame with anassociated CFN number must be transmitted over the air at a given time.If there are several NodeBs and Iub/Iur links involved, all NodeBs haveto transmit that particular frame at the same time. Assuming that thedelays over the Iub links differ, the serving RNC must send the framewith a sufficient time-offset, so that the frames are received at alltransmitting NodeBs on time. Those NodeBs “behind” a fast Iub link mustbuffer the frames until the scheduled time for transmission.

To supervise this function, 3GPP TS 25.402 specifies parameters defininga “Receiving Window”, which facilitates monitoring of whether frames arereceived early or late at a NodeB. These parameters are illustrated inFIG. 3. The window serves as a ‘target’ so that ToAWS (rime of ArrivalWindow Start point) defines the earliest point and the minimum bufferingcapability needed by the NodeB, while the ToAWE (Time of Arrival WindowEnd point) defines the latest ‘desired’ arrival time of a frame. Framesreceived during the period between ToAWE and a LtoA (Latest Time ofArrival) point are considered late, but not too late for transmission.Frames received after LtoA are discarded. The standard specifies how theNodeB shall report to the RNC in case the frames are received outsidethe widow, so that the RNC can adapt its offset accordingly: for eachframe received outside the Receiving Window, the NodeB shall respondwith a “Timing Adjustment” frame, indicating the ToA (Time of Arrival)of the frame, so that the serving RNC can adjust its offsets.

In order to make sure that all NodeBs receive frames on time, the FrameSynchronization must be in a “worst-case” mode, where the Iub/Iur “leg”with the worst delay is ruling the offset. A similar approach may beapplied to ensure frame synchronisation in the uplink direction.

The standard 25.402 supports certain tools Or Timing adjustment and ToAmonitoring on the Iub/Iur interfaces. One such tool simply involvestrusting the “Receiving Window” function as described above. However, inorder to receive frequent and trustworthy measurements of theframe-arrival process, it would be necessary to define a very narrowwindow such that frequent feedback from the receiving node (RNC orNodeB) is achieved. This is far from ideal, as to do so would generate alot of reverse link traffic. With very small windows, the messages fromdifferent receiving nodes could also be ambiguous, with one receivingnode reporting a need to reduce the offset, while another is reporting aneed to increase it. In practice, a rather large window (based onpre-configured parameters settable by the operator) tends to be defined.Timing adjustments are assumed to be very rare. Thus, thewindow-mechanism is not used in practice for offset tuning—rather it isused as a tool for recovering from fault events. Of course the result ofadopting this approach is that there is no means for actively monitoringand adapting the offset timing in real or near real-time, and the offsetdelay used for frame synchronisation is likely to unnecessarily delaythe end-to-end transfer of data, especially during periods of relativelylight loading of the data link (or a favourable transport topology).

A second tool for determining timing adjustments involves using DLSynchronization Control frames. The specification 25.402 defines thatthe NodeB must always respond to the receipt of such a frame with a ULSynchronization Control frame including the value of the ToA of the DLSynchronization Control frame. However, the DL Synchronization Controlframes can only be sent when no DL data frames are sent. This means thatthe ToA monitored with this procedure does not provide a reliablemeasure of the “true” ToA characteristics of data frames. In addition,in order to obtain high quality statistics of the ToA process, it wouldbe necessary to perform frequent ToA measurements. A procedure using DLSynchronization Control frames would result in excessive extra trafficin both the up- and downlink directions. For an “active” connection witha lot of traffic, it is not possible to use this function. It is notedthat there is no standardised solution for the uplink direction,equivalent to this approach. Uplink solutions are vendor specific.

SUMMARY

The current solution for achieving frame synchronisation has a majordrawback, namely the potential unnecessary buffering and delays in bothuplink and downlink. A hypothesis put forward here is that different RABtypes (and traffic sources) place different demands on the delay and onthe Frame Synchronization procedure. Whilst current FrameSynchronization designs may be very well suited for speech, thesedesigns do not necessarily provide the best possible service forAcknowledged Mode (AM) bearers, transporting for example data.

Speech services belong to the “Conversational” class in terms of QoSclassification. This QoS class has the most stringent delay requirementsregarding delay and delay jittering. Speech services should beprioritised over Iub interface, resulting in tight delay requirementsfor Speech. Relative to other services, the delay offsets are thereforemost stringent for Speech services. Speech services are typicallyrealised using TM bearers, although this need not be the case (e.g.Voice over IP).

Speech is particularly sensitive to delay jittering, due to limitedbuffering in the end-to-end path between the speech encoder and decoder.Once the speech encoder-decoder pair is synchronized to a given (oneway) delay, large jittering may cause frames to be lost resulting in areduction of the subjective speech quality. It is therefore mostimportant to maintain the delay and pacing of the transfer, as in thecurrent Frame Synchronization solutions. The absolute delay is of lessimportance given the insensitivity of human perception to short delays(e.g. less than 150 ms) in verbal communication. However, the acceptabledelay variation (jitter) during a call is limited to 1 ms.

Packet Switched (PS) bearers belonging to the Interactive or Streamingclass have relatively loose requirements on delay. PS bearers cantherefore be realized using the AM mode, in order to increase radioresource efficiency. Due to the non-stringent formal requirements ondelay, the offset related to Frame Synchronization can be set to ratherloose values.

Due to the loose delay requirements in terms of QoS, a commonmisconception is to assume that packet-data performance is non-sensitiveto delay. Indeed, packet-data services work also over high-latencyconnections, but the performance is critically dependent on the latency.This is particularly true for highly interactive traffic such Telnet,which is characterized by its request-response nature. In the case ofgaming applications, it well known that players behind low-latencyconnections have a competitive edge over players experiencing longdelays. In addition, we note that also web-traffic and FTP transferssuffer if the end-to-end delay is high. In these cases, it is not onlythe slow response to human action that matters (as in gaming andTelnet), but also the requirements set by the TCP protocol. TCPperformance is highly dependent on the end-to-end delay through itscongestion control mechanisms and TCP session setup and releaseprocedures.

Thus, compared to Speech services, packet data services are much lesssensitive to jitter, but potentially more sensitive to delay. There istherefore a strong incentive to provide the lowest link latency forpacket-data bearers that can be supported at any moment of time, even ifsome delay jittering would be the cost.

According to a first aspect of the present invention there is provided amethod of transporting data over the Iub/Iur interface of a UMTSTerrestrial Radio Access Network, UTRAN, in which frame synchronisationat the receiving node is achieved by delaying the sending of data framesfrom the sending node by an offset delay, the method comprising:

-   -   for speech services, defining said offset delay as a        substantially fixed delay; and    -   for data services, defining an initial offset delay and        dynamically varying the delay at the sending node based upon        Time of Arrival feedback received from the receiving node, to        optimise the offset delay value.

According to a second aspect of the present invention there is provideda node for use in a UMTS Terrestrial Radio Access Network, UTRAN, thenode comprising:

-   -   means for transmitting data frames to one or more receiving        nodes via Iub/Iur interfaces with an initial timing offset; and    -   means for applying dynamically varying the offset for data        services based upon Time of Arrival feedback received from the        receiving node(s), whilst maintaining the timing offset        substantially constant for speech services.

It is an object of the present invention to overcome or at leastmitigate the disadvantages of known frame synchronisation techniquesover the Iur/Iub interfaces. This and other objects are achieved byproviding processes which enable a more continuous monitoring of theToAs of frames at the receiver.

According to a second aspect of the present invention there is provideda method of optimising the timing offsets with which data frames aretransmitted over the Iur/Iub interfaces of a UMTS Terrestrial RadioAccess Network, UTRAN, the method comprising:

-   -   for a given Iur/Iub interface or set of Iur/Iub interfaces over        which identical user plane data is to be sent, defining a        duration of a data frame receiving window for use by the        receiving node(s);    -   transmitting data frames from a sending node with an initial        timing offset;    -   reducing the timing offset at the sending node in a stepwise        manner; and    -   adjusting the timing offset at the sending node in response to        the receipt of late Time of Arrival error reports at the sending        node.

In certain embodiments of the present invention, the initial timingoffset may be set to a value sufficient to ensure a likelihood that theframes will be received at the or each receiving node within the definedreceiving window. In other embodiments, the initial timing offset may beset to a value short enough to ensure a likelihood that early frames arereceived outside of that defined window, thus triggering the sending ofa late Time of Arrival error report.

According to a third aspect of the present invention there is provided amethod of optimising the timing offsets with which data frames aretransmitted over the Iur/Iub interfaces of a UMTS Terrestrial RadioAccess Network, UTRAN, the method comprising:

-   -   for a given Iur/Iub interface or set of Iur/Iub interfaces over        which identical user plane data is to be sent, defining a        duration of a data frame receiving window for use by the        receiving node(s);    -   transmitting data frames from a sending node with an initial        timing offset;    -   at the or each receiving node, collecting and/or computing Time        of Arrival statistics for received data frames;    -   periodically reporting said statistics to the sending node; and    -   adjusting the timing offset at the sending node on the basis of        the received statistics.

The statistics collected at a receiving node may be any suitablestatistics relating to Times of Arrival. Preferably, these include oneor more of; the mean, minimum, maximum, and variance of Times Of Arrivalfor data frames received during some time period, that time periodtypically being the time period since the last statistics report wassent to the sending node.

The method may comprise sending from the sending node to the or eachreceiving node instructions identifying the statistics to be collectedat the receiving node and sent to the sending node. The instructions mayidentify the regularity with which the statistics must be sent, orevents defining when the statistics should be sent (e.g. upon a changein one or more parameters).

The method may comprise sending polling requests from the sending nodeto the or each receiving node instructing the return of statistics.

The sending node may be one of a Radio Network Controller, RNC, or aNodeB. The or each receiving node will be the other of an RNC or NodeB.The different aspects of the present invention may be applied in one orboth of the uplink and downlink directions.

The different aspects of the present invention are particularlyapplicable in a Macro Diversity scenario, where identical user planedata is being transmitted between User Equipment, UE, and an RNC via twoor more NodeBs.

Adjustment of the timing offset is performed by intelligence implementedat the sending node. The offset may be varied using some predefinedalgorithm and the information received from the or each receiving node.

According to a fourth aspect of the present invention there is provideda node for use in a UMTS Terrestrial Radio Access Network, UTRAN, thenode comprising:

-   -   means for transmitting data frames to one or more receiving        nodes via Iub/Iur interfaces with an initial timing offset;    -   means for reducing the timing offset in a stepwise manner; and    -   means for adjusting the timing offset in response to the receipt        of late Time of Arrival error reports.

According to a fifth aspect of the present invention there is provided anode for use in a UMTS Terrestrial Radio Access Network, UTRAN, the nodecomprising:

-   -   means for transmitting data frames to one or more receiving        nodes via Iub/Iur interfaces with an initial timing offset; and    -   means for receiving statistical data sent periodically from the        or each receiving node and relating to the Times of Arrival of        data frames at respective receiving nodes, and for adjusting the        timing offset on the basis of the received statistics.

The node of the third or fourth aspect of the present invention may be aRadio Network Controller or a NodeB.

The terminology used here to define the communications network and theradio access network is specific to 3G, i.e. UMTS, UTRAN, and Iub/Iur.However, the skilled person will appreciate that the present inventionis also applicable to enhancements and successors of 3G, including 4G,whatever the terminology used in the relevant standards and protocols todescribe equivalent components and interfaces.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically a UTRAN of a UMTS network;

FIG. 2 illustrates schematically the user plane protocols providing forcommunication between an RNC, NodeB, and UE of the UTRAN of FIG. 1;

FIG. 3 illustrates frame synchronisation requirements at an RNC or NodeBof the UTRAN of FIG. 1;

FIG. 4 illustrates schematically a timing offset optimisation procedureaccording to a first embodiment of the present invention; and

FIG. 5 illustrates schematically a procedure for optimising timingoffsets according to a second embodiment of the present invention.

DETAILED DESCRIPTION

The comparably low sensitivity to jittering for packet switched serviceshas made it possible to realize packet switched domain bearers using theAcknowledged Mode RLC. By itself, AM-mode typically also introducesdelay jittering, since SDUs suffering from transmission losses aredelayed until re-transmissions repair them. In-sequence delivery furtherincreases the traffic burstiness over the RAB egress Service AccessPoint (SAP). Burstiness is in fact an inherent feature of IP traffic,due to the non-existent QoS guarantees in today's IP backbone networks.In case there are some end-to-end requirements on the delay of thepackets, as for Streaming applications, these requirements are typicallyhandled by buffering before play-out.

In addition, it is noted that no strict pacing of the Frames towards theAM RLC is required. This is true, since the AM RLC cannot maintain anypaced delivery over its egress SAPs. At times of low Frame Protocollatency, the RLC round trip time (RTT) could be shortened, and theend-to-end perception of the service would be improved.

The requirement for setting the offset delay for frame transmissionsover the Iub/Iur interface in the UTRAN has been discussed above withreference to FIGS. 1 to 3. It will be appreciated that for minimalend-to-end data transmission delay with rare frame losses, as isdesirable for packet data services, it is desirable to have the framesreceived as close to the Latest Time of Arrival (LtoA) as possible (seeFIG. 3) with rare receptions in the “Too Late” region. As noted above,the existing procedures for setting the offset delay do not provideefficient means to achieve this in an optimal way. Either ToA data isreceived by the frame sender only rarely, so that only a very prudentsolution with excessive offsets is feasible, or it is necessary to sendsignificant extra measurement traffic over the Iub/Iur.

A first preferred solution provides for an adaptive transmission offsetcontrol method, by which the delay over the Iub/Iur is continuouslyadapted to the prevailing conditions in the transport network. Usingthis method, the lowest possible delay—at any point in time and for anytransport network topology—can in principle be achieved. The ToAWE limitis continuously challenged by successively (but slowly) decreasing thetransmission offset at the sending node, with Timing Adjustment Framesbeing issued by the receiving node when frames are received after theToAWE point. When a Timing Adjustment Frame is received by the sendingnode, the timing offset is increased with an amount which is largerelative to a single reduction step.

The procedure is illustrated in FIG. 4. The lowest limit of the offsetis continually probed at the sending node by decreasing the offset by anamount or step α for each successively transmitted frame. When the limitis hit, i.e. a first frame is received after ToAWE and a TimingAdjustment Frame received by the sending node, the offset is increasedby a step β (where β=kα and k is a constant greater than 1). Note thatthe average number of Timing Adjustment Frames relative to the number ofdata frames can be determined from the fraction α/β. Note also that thevariance of the transport network delay should preferably be reflectedin the steps of α and β: if the delay variations are very low, themethod can be operated with very small steps, i.e. arriving at a stableoperating point very close to the “optimal” offset.

The steps α and β may be of fixed size, or one or both may be ofvariable size. In the latter case, the step size may be variedadaptively, depending upon feedback timing information received at thesending node from the receiving node.

The mechanism proposed here is applicable using the Release99 version of3G standards 25.402, 25.427 and 25.435. Of course the mechanism is alsolikely to be applicable to later versions and to other standards.

An alternative solution to the problem of optimising framesynchronisation is to define and implement a measurement function at areceiving node (e.g. NodeB) which, for each Transport Bearer, monitorsthe ToA process, and reports statistics of the arrival process to thesending node (e.g. RNC). These statistics will typically be collectedover some predefined time period. Based on the received statisticalinformation, intelligence at the RNC will judge if there are reasons toincrease or decrease the timing offset. This is illustratedschematically in FIG. 5.

The statistical information of the ToA process might be any standardstatistical information. However, useful and easy to produce examplesare the mean, minimum and maximum values of the ToA, and possibly thevariance, over the predefined period. Using the received statistics, itis easy for the sending node to decide if the timing offset can bereduced, or if it must be increased.

Based on the received ToA statistics, the receiving node may decide totrade Frame Handling reliability for transmission delay: If a certainproportion of frame losses is acceptable, the sending node may decide toset the offset so that a certain percentile of transmitted frames “hit”the receiving node in the “Too Late” region. This contrasts with theconventional approach which is to set the offset so that frames never,or only very rarely (e.g. in the event of a fault) arrive in thisregion.

The statistical reporting function implemented at the receiving nodeshall be configurable by the sending node. It shall be possible toenable or disable measurements. It shall also be possible to define theperiod over which the measurement reports are collected, and when theyare sent. For example, the function may be configured such that a ToAMeasurement Report shall be transmitted in the uplink after each blockof 100 DL frames. Optionally, it shall be possible to define the periodrelative to the CFN, which is increasing irrespective of whether or notdata is transmitted.

1. A method of optimizing the timing offsets with which data frames aretransmitted over the Iur/Iub interfaces of a UMTS Terrestrial RadioAccess Network, UTRAN, the method comprising: for a given Iur/Iubinterface or set of Iur/Iub interfaces over which identical user planedata is to be sent, defining a duration of a data frame receiving windowfor use by the receiving node(s); transmitting data frames from asending node with an initial timing offset; reducing the timing offsetat the sending node in a stepwise manner using a relatively small stepvalue α; and adjusting the timing offset at the sending node byincreasing the timing offset using a relatively large adjustment value βin response to the receipt of one or more late time of arrival errorreports at the sending node, wherein the relatively small step value αis smaller than the relatively large adjustment value β, and whereinβ=kα and k is a constant greater than
 1. 2. A method according to claim1, wherein the relatively large adjustment value exceeds a combinationof multiple ones of the relatively small step values.
 3. A method ofoptimizing the timing offsets with which data frames are transmittedover the Iur/Iub interfaces of a UMTS Terrestrial Radio Access Network,UTRAN, the method comprising: for a given Iur/Iub interface or set ofIur/Iub interfaces over which identical user plane data is to be sent,defining a duration of a data frame receiving window for use by one ormore receiving node(s); transmitting data frames from a sending nodewith an initial timing offset; reducing the initial timing offset usinga first relatively small timing offset value α until a report isreceived that a transmitted data frame is outside of the data framereceiving window; in response to the report, increasing the reducedtiming offset using a second relatively large timing offset adjustmentvalue β; at the one or more receiving nodes, collecting and/or computingtime of arrival statistics for received data frames; reporting saidstatistics to the sending node; and adjusting the timing offset at thesending node on the basis of the received statistics, wherein β=kα and kis a constant greater than
 1. 4. A method according to claim 3, whereinthe collected statistics include one or more of: the mean, minimum,maximum, and variance of times of arrival for data frames receivedduring some time period.
 5. A method according to claim 4, furthercomprising: sending from the sending node to the one or more receivingnodes instructions identifying the statistics to be collected at the oneor more receiving nodes and sent to the sending node.
 6. A methodaccording to claim 5, wherein said instructions identify a regularitywith which the statistics must be sent or events defining when thestatistics should be sent.
 7. A method according to claim 3, furthercomprising: sending polling requests from the sending node to the oreach receiving node instructing the return of statistics.
 8. A methodaccording to claim 3, wherein the sending node is one of a Radio NetworkController, RNC, or a NodeB, and the one or more receiving nodes is theother of an RNC or NodeB.
 9. A method according to claim 3, wherein saidinitial timing offset is sufficient to ensure a likelihood that theframes will be received at the one or more receiving nodes within thedefined receiving window.
 10. A method according to claim 3, wherein therelatively large timing offset adjustment value exceeds a combination ofmultiple ones of the relatively small timing offset values.
 11. A nodefor use in a UMTS Terrestrial Radio Access Network, UTRAN, where for agiven Iur/Iub interface or set of Iur/Iub interfaces over whichidentical user plane data is to be sent, there is a data frame receivingwindow having a defined duration, the node comprising: a transmitter fortransmitting data frames to one or more receiving nodes via lub/lurinterfaces with an initial timing offset; electronic control circuitryarranged to: reduce by an amount a the timing offset in a stepwisemanner, and adjust the timing offset by increasing an amount β, reducedtiming offset in response to the receipt of one or more late time ofarrival error reports, wherein the relatively small step value a issmaller than the relatively large adjustment value β, and wherein β=kαand k is a constant greater than
 1. 12. A node according to claim 11wherein the increase exceeds a combination of multiple steps.
 13. A nodefor use in a UMTS Terrestrial Radio Access Network, UTRAN, the nodecomprising: means for transmitting data frames to one ore more receivingnodes via lub/lur interfaces with an initial timing offset; means forreducing the initial timing offset using a first relatively small timingoffset value α until a report is received that a transmitted data frameis outside of a data frame receiving window; means, in response to thereport, for increasing the reduced timing offset using a secondrelatively large timing offset adjustment value β; wherein β=kα and k isa constant greater than 1, and means for receiving statistical data sentperiodically from the or each receiving node and relating to the timesof arrival of data frames at respective receiving nodes and foradjusting the timing offset on the basis of the received statistics. 14.A node according to claim 13, wherein the relatively large timing offsetadjustment value exceeds a combination of multiple ones of therelatively small timing offset values.
 15. A node according to claims 11or 13, wherein the node is a Radio Network Controller.
 16. A nodeaccording to claim 11 or 13, wherein the node is a NodeB.